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Abstract. We design a library for binary field arithmetic and we supply a core 
API which is completely developed in DLAL, extended with a fix point formula. 
Since DLAL is a restriction of linear logic where only functional programs with 
polynomial evaluation cost can be typed, we obtain the core of a functional pro- 
gramming setting for binary field arithmetic with built-in polynomial complexity. 



1 Introduction 

Embedded systems (smart cards, mobile phones, sensors) are very heavy on resources. 
Low memory and computational power force programmers to choose specific algo- 
rithms and fine tune them in order to carefully manage the space and time complexity. 
There is an applicative domain where these constraints on resources cause serious diffi- 
culties: the implementation of cryptographic primitives, that is the foundation for strong 
security mechanisms and protocols. 

We have started reasoning about a controlled programming setting, that should en- 
able the certification of resource usage (memory and computation time), in a functional 
programming language. We are aware of different approaches to solve analogous prob- 
lems, for instance the Computer Aided Cryptography Engineering (CACE) European 
project"* whose mission is "to enable verifiable secure cryptographic software engi- 
neering to non-experts by developing a toolbox which automatically produces high- 
performance solutions from natural specifications". 

What if difficulties on time/space complexity were automagically overcome by im- 
posing an appropriate type discipline to the programming language? 

This paper describes preliminary results on how to devise a programming lan- 
guage that grants a natural programming style in the implementation of specific number 
theoretic algorithms, in combination with a type discipline which ensures complexity 
bounds. More precisely, we investigate how to achieve implementation of number the- 
oretic algorithms with certified running time bounds by exploiting logical tools under 
the prescriptions of Implicit Computational Complexity (ICC) [1]. We recall that ICC 
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mainly aims at searching strong mathematical roots for computational complexity the- 
ory. The logical approach to ICC extracts functional language primitives from logical 
systems under the Curry-Howard analogy. The logical system for ICC we focus on is 
DLAL [2]. It derives from linear logic. Its formulas can be types of /l-terms. A A-term 
M typable in DLAL reduces to its normal form in a time which is a polynomial in the 
dimension of M. 

We propose to put this theory into practice by developing and implementing a core 
library of combinators, namely /l-terms, typeable in DLAL. The library currently im- 
plements a subset of functionalities which are needed for binary field arithmetic (cf., 
e.g., [3, Section 11.2]). The practical relevance of completing such a library is to import 
functional programming technology with a known predetermined complexity into the 
area of applied cryptography. 

Contributions. Defining a core hbrary that correctly implements finite field arithmetic 
is a result in itself. The reason is that when programming non obvious combinators 
typeable in DLAL, the main obstacle lies in the application of the standard divide-et- 
impera paradigm: first split the problem into successively simpler ones until the solu- 
tion becomes trivial, then compose the results. Composition is the harmful activity as 
soon as we face complexity issues. For example, using the output of a sub-problem, 
which results from an iteration, as the input of another iteration may yield a computa- 
tional complexity blowup. This is why, in DLAL, naively manipulating lists by means 
of iterations, can rapidly "degrade" to situations where compositions which would be 
natural in standard A-calculus simply get forbidden. It is for this reason that /l-terms 
in DLAL which implement the low level library with finite field operations are not the 
natural ones that we could write using /l-terms typeable in the System F [4]. 

To overcome the need of programming with non natural /l-terms, we follow [5], 
which promotes standard programming patterns to assure readabiUty and soundness of 
functional programs. We build an experimental API on top of the core library, which 
exports standard programming patterns. The goal of supplying an API is to help non 
experts writing /l-terms which are not directly typeable in DLAL, but which, roughly 
speaking, can be checked to compile into /l-terms with a type in DLAL. 

Related Works on Polynomial Time Languages. A programming language inspired 
by Haskell is described in [6]. The programs that can be developed in it belong to the 
class of polynomial time functions because the language inherits the principles of the 
/l-terms, or, equivalently, of the proof-nets of LAL [7]. However, we are not aware of 
any attempt to exploit it to program libraries with a real potential impact. The approach 
of [6] to the development of a real programming language for polynomial time compu- 
tations is quite orthogonal to ours. We proceed bottom-up, showing that a reasonably 
interesting library can be developed inside DLAL. Then, we import standard program- 
ming patterns which were compatible with the typing discipline of DLAL. In [6], the 
language is given under the assumption that its primitives will really be used. 

The same occurs in [8] and [9]. The former extends /l-calculus to give formulas of 
SLL [10]. The latter introduces POLA, a progranmiing language which mixes object 



oriented and recursion schemes for which an interpreter is also available^. The best 
developed project we are aware of, and which brings theoretical results related to the 
world of polynomial time bounded functions "down to" the practical level, is based 
on [1 1, 12]. The language exploits formulas of a smartly crafted version of multiplica- 
tive linear logic as types and is based on recursion schemes a la System T. We are still 
far from those levels of migration of theory to practice. 

Our main distinguishing feature is to remain loyal to the theoretical properties of 
DLAL, while allowing programming with standard patterns of functional programming. 

2 Typed Functional Assembly 

A-calculus. Given a set 'V, which we range over by any lowercase Latin letter, the set 
A of /l-terms, which we range over by the uppercase Latin letters M, N, P, Q, R, this set 
contains terms generated as follows: 

M r.^'V \ Ax.M \(M)M. (1) 

The set of free variables in M is fv(M). The set A" of values of our computations, which 
we range over by the uppercase Latin letters V, W, X, is defined as follows: 

V Ax.V\{x)V. (2) 

We remark that A" coincides the standard yS normal forms. 



xiix " Ax.MiiAx.V ^ {M)Nii{x)V ®^ {M)N\^W 



Fig. 1. Big steps rewriting relation U. on A with results in A' 

Big Steps Rewriting Relation on A-calculus. The relation J|c AxA^ is inductively 
defined in Figure 1 . 

2.1 Type assignment 

We introduce a type assignment TFA which gives formulas of Linear Logic as types 
to A-terms. In fact, TFA is DLAL [2] whose set of formulas is quotiented by a specific 
recursive equation. We recall that adding a recursive equation among the formulas does 
not negatively affect polynomial time soundness of DLAL normalization which only 
depends on the structural constraints that the process of formula construction puts on 
the form of derivations [1]. 
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A\r\- Ax.M-AA^B A,A' \r h (M)N:B 

0M,ri-M:A A\rhN-M A'\x-M,r' hM:B 



^ I §r h M:§A ^ I r.r h Mfl^}:B 

A\rt-M:A aifw{A,r) A\^^-M■.Va.A 
zl|ri-M:VQ'.A zl I r h MiAL'^/J 

Fig. 2. Type assignment system TFA 



lypes for TFA. Given a set of formula variables, which we range over by lowercase 
Greek letters, the set IF of formulas, that we range over by the uppercase Latin letters 
A, B, C, D, is defined as follows: 

A::=a\A^A\]A^A\ \faA \ §A 

Note that modal formulas \A can occur in negative positions only. We obtain the set 
of types T when we consider the quotient of T by the following fix-point equation: 

S = Vor.SM (3) 

where S[ck1 = (B2 -^a)^ ((B2(8)§) -^a)^ a and 3.2 is defined in Figure 3. We say S 
is the type of Sequences. Thus, we actually use formulas which are equivalence classes 
of types in T. 

Note that once we use S as type of a /l-term M, we can equivalently use any of its 
"unfolded forms" as type of M as well. In Figure 3, we also introduce relevant types we 
use to develop our first level library. As a notation, A[^/„] is the clash free substitution 
of B for every free occurrence of a in A (here, clash-free means that occurrences of free 
variables of B are not bound in A[^/a,]). 



Type assignment TFA. We give the type assignment system TFA in Figure 2. In this 

formal system, we have judgments of the form A \ F v M : A where context A is 
exponential, while context F is linear. Any context is a finite domain function x\ : 
A\, ...,x„ -.An with domain [xi,..., x„], and range {Ai, . . . ,A„] in the codomain of the 
set of types. Every pair x:A of any kind of context is a type assignment for a variable. 

Tuples as primitives. The definition of tuples in Figure 3 supports the introduction of 
the tuples as primitives, as follows. Extending A-calculus with tuples means adding the 
following clauses to (1): 



M ::= ...\{M,...,M) \ A{x, . . .,x).M. 



(4) 



lype 


Definitions 


Finite t5?pes 


B„[Qr] = a-o- ■ --od-oa 
B„ = Var.B„[a] 


Tunles 


(Ai(8i. . .®A„)[Qr] = Ai -o oA„-oa 

(Ai0...0A„) = VQr.(Ai®...(8>A„)[Qr]-oQf 


Church numerals 


U[a] = !(a-oa)-o§(Qr-oQr) 
U = Va.UM 


Lists 


L(A)[Qr] = \(A-oa-oa)-o%(a-oa) 
L(A) = Va.L(A)[a] 


Church words 


Lj = L(B2) 



Fig. 3. Relevant (defined) types 



So, values in (2) also include: 

y ::=... I (y,...,y), (5) 

and the set of rules in Figure 1 must contain: 

MiUVi ■■■ M„\iV„ 

<Mi,...,M„>u<yi,...,y„> 

MiiA{xu...,x„}.V N\i{Vi,...,Vn} VC'V... •■•/"/.„} 

Finally, we add the following derivable rules to those ones in Figure 2: 

^i|rihMi:Ai ■■■ A„\r„hM„:A„ 
/li.../l„ |ri...r„ l-<Mi,...,M„):(Ai®...®A„) 

I r,xi:Ai...x„:A„ h M:B 

A\r\- A{xu...,x„).M:iAi<S:...'S>An)^B ^ ® 

Saying that the here above rules are derivable means that we use tuple as abbreviations, 
as follows: 



{Mu...,M„} = Ax.{...i{x)Mi)...)Mn 
A{x\, . . .,x„).M = Ap.{p)Axi Ax„.M 



(6) 
(7) 



3 A Library for Binary Field Arithmetic 



In this section, we present a library of lambda-terms for the arithmetic in binary fields 
written in DLAL. The library is organized in functional layers, as shown in Figure 4. 

The lowest layer contains basic definitions and it is interpreter- specific. We have 
currently implemented the library with LCI*', an interpreter for pure i-calculus. We thus 
needed to define basic types, such as Church words, or DLAL-specific combinators. The 
core library layer contains all the combinators to work on basic types. We put particular 
care in the definition of common functional-programming patterns in DLAL, and to 
reuse them, whenever possible, while defining other combinators. Finally, in the binary 
field arithmetic layer we group all the combinators related to operations over binary 
polynomials, like addition, multiplication and modular reduction. 

In future work, we plan to extend the library by implementing other layers, such as 
arithmetic of elliptic curves or other cryptographic primitives, on top of the binary field 
arithmetic layer. 



Cryptographic primitives: elliptic curves cryptography, . . . 
Binary field arithmetic: addition, (modular reduction), square, 
multiplication, inversion. 

Core library: operations on bits (xor, and), operations on se- 
quences (head-tail splitting), operations on words (reverse, drop, 
conversion to sequence, projections); meta-combinators: fold, map, 
mapthread, map with state. 

Basic definitions and types: booleans, tuples, numerals, words, 
sequences, basic type management and duplication. 

Fig. 4. Library for binary field arithmetic 

In the following subsections we present type and behaviour of the relevant combi- 
nators, while the fuU definition as /l-term is in Appendix A. 

3.1 Basic Definitions and l^pes 

In Figure 5, we give names to those formulas which are types we actually use in the 
library and we identify the /l-terms that we define as canonical values of the corre- 
sponding type. In every Sequence [b„_i ... bo | and Church word {b„_i ... bo} the least 
significant bit (l.s.b.) is bo, while the most significant bit (m.s.b.) is b„_i . 
In DLAL, we can derive the rule paragraph lift: 

I H M:A^B 
I h §[M]:§A^§£ 

where §[M] = Ax.{M)x is the paragraph lift of M. As obvious generalization, n con- 
secutive applications of the §L rule define a lifted term §"[M] = Ax.{. . . Ax.{M) x...)x, 
that contains n nested §[•]. Its type is §"A -o §"B. Borrowing terminology from proof 
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(tjrped) Values 


Booleans 


1 = Axyz.x : B2 
= Axyz.y : B2 
-L = Axyz.z . 02 


Tuples 


<Mi, . . . , M„> = Ap.{. . . . . .) M„ : (Ai®. . .®A„) 


Church numerals 


u£ = Afx.x : U 

n = Afx.(J) ...(/) x:U 

n 


Church words 


le\ = Afx.x : L2 

{b„_i . . .bo} = Afx.((f)b„-0 . . . ((/)bo)x : L2 


Sequences 


[s] = Atc.(t) _L : S 

[b„_i ... bo] = Atc.(c) <b„_, , [b„-2 . . . bo]> : S 



Fig. 5. Canonical values of data-types 



nets, the application of n paragraph lift of M embeds it in n paragraph boxes, leaving 
the behaviour of M unchanged: 

(§"[M])A^||(M)Ar. 

The combinator bCast"' : B2 -o §'"'^^82 embeds a boolean into m + 1 paragraph boxes, 
without altering the boolean: 

(bCast'")b Jib. 



The combinator bV; : B2 -o (82®- • -082), for every t > 2, produces t copies of a 
boolean: 

t 

(bV,)b|Kbr^). 

The combinator tCast™ : (82(8)82) -o §'"+'(B2®B2), for every m > 0, embeds a pair of 
bits into m+\ paragraph boxes, without altering the structure of the pair: 

(tCast")<bo,bi>U<bo,bi). 

The combinator wSuc : 82 -0L2 -0L2 implements the successor on Church words: 

((wSuc) b) {b„_i . . . bo} U {b b„_i . . . bo}. 



The combinator wCast"" : L2 -° §"'^'L2, for every m > 0, embeds a word into m + I 
paragraph boxes, without altering the structure of the word: 

(wCast'"){b„_i...bo}|Kb„_i...bo}. 

t 

The combinator wV™ : L2 -<> §"^'(1.2®- • •<8L2), for every f > 2, m > 0, produces t 
copies of a word deepening the result into m+ 1 paragraph boxes: 

(wvn {b„_i ... bo} U ({b„-i...bo},..".,{b„_i...bo}). 

3.2 Core Library 
Operations on Bits. 

The combinator Xor : B2 ^B2 ^B2 extends the exclusive or as follows: 

((Xor)Q)Qll0 ((Xor) 1)1 lis 

((Xor)0)l|il ((Xor) 1)0 U 1 

((Xor)±)b Ji b ((Xor)b)± J) b (where b : B2). 

Whenever one argument is ± then it gives back the other argument. This is an applica- 
tion oriented choice. Later we shall see why. 
The combinator And : B2 ^B2 ^82 extends the and as follows: 

((And)0)0JlS ((And) 1)1 111 

((And)0)l|iS ((And)l)(8U8 

((And)±)b ± ((And)b)± U ± (where b : B2). 

Whenever one argument is ± then the result is ±. Again, this is an application oriented 
choice. 

Operations on Sequences. 

The combinator sSpl : S -o (B2®S) splits the sequence it takes as input in a pair with 
the m.s.b. and the corresponding tail: 

(sSpl) [b„_i ... bo] ^ (b„_i, [b„_2 . . . bo]>. 
Operations on Cliurcli Words. 

The combinator wRev : L2 -0L2 reverses the bits of a word: 

(wRev) {b„_i . . . bo) IL {bo . . . K-\}- 

The combinator wDrop± : L2 ^L2 drops all the (initial) occurrences^ of ± in a word: 

(wDrop±) {± . . . ± K-\ ■ ■ ■ bo} li {b„-i . . . bo}. 

' The current definition actually drops all the occurrences of ± in a Church word, however we 
shall only apply wDropJ. to words that contain J. in the most significant bits. 



The combinator w2s : L2 ^ §S casts a word into a sequence: 

(w2s) {b„_i ... bo) U [b«-i ... bo]. 

The combinator wProj : LCBj) -0L2 projects the first component of a list of pairs: 

» . . . ((/) (ao, bo» X li {a„_i . . . ao} . 

Similarly, wProj2 : LCBj) -o L2 projects the second component. The argument of 
wProj has not the form {(a„_i, b„_i) . . . (ao, bo)) because its elements are not booleans. 
We shall adopt the same convention also for the forthcoming meta-combinators. 

Meta-combinators on Lists. Meta-combinators are A-terms with one or two "holes" 
that allow to use standard higher-order programming patterns to extend the API. Holes 
must be filled with type constrained i-terms. We discuss how to use meta-combinators 
in order to efl'ectively implement arithmetic in Section 3.3, after their introduction here 
below. 

The first meta-combinator we deal with is Map[-]. Let F : A ^ B be a closed term. 
Then, Map[F] : L(A) -o L(B) applies F to every element of the hst that Map[FJ takes as 
argument, and yields the final list, assuming (F) b, I) bj, for every Q <i <n-\: 

(Map[F]) Xfx.iif) b„-i) . . . ((/) bo) x ^ Afx.{{f) K-x) ■ ■ ■ ((/) ^o) ^ 

The second meta-combinator is Fold[-, •]. Let F : A-oB-oB and S : B be closed terms. 
Let also Cast" : B -o §B. Then, Fold[F, S] : L(A) -o §B, starting from the initial value 
S, iterates F over the input list and builds up a value, assuming ((F)b,)b^ JJ. b^^p for 
every < i < « - 1, and setting b^ = S and h'„ = b': 

(Fold[F, S]) Afx.iif) bn-i) . . . ((f) bo) xliW 

The third meta-combinator is MapState[-]. Let F : (A^S) -o (B(g)5) be a closed term. 
Then, MapState[F] : L(A) -o S ^ L(B) apphes F to the elements of the input hst, 
keeping track of a state of type S during the iteration. Specifically, if (F) {b„ s,) JJ. 
{b'., s,+i), for every < j < n - 1: 

((MapState[F]) Afx.((f) b„_i) ...((f) bo) x) So ]}. Afx.((f) h'„_,) ...((f) h'^) x 

Finally, the fourth meta-combinator is MapThread[-]. Let F : B2 -0B2 -°A be a closed 
term. Then, MapThread[FJ : L2 ^L(A) applies F to the elements of the input hst. 
Specifically, if ((F) a,) b, JJ. c„ for every < i <n - I: 

((MapThread[F]) {a„_i . . . ao)) {b„_i . . .bo) i) Afx.((f) c„_i) . . . ((/) Co) x 

In particular, MapThread[/k!./lfc.(a, b}] : L2 -0L2 -oL(B2) is such that: 



((MapThread[/la.Afc.(a, b}]) {a„_i . . . ao)) {b„_i . . . bo) JJ 

Afx.((f) (a„_i, b„_i)) . . . ((/) (ao, bo)) x 



3.3 Binary Field Arithmetic 

We start by recalling the essentials on binary field arithmetic. For wider details we 
address the reader to [3, Section 11.2]. Let p{X) e FjlX] be an irreducible polynomial 
of degree n over Fi, and let j8 e F2 be a root of piX) in the algebraic closure of F2 . Then, 
the finite field ¥2- ^ F2[Z]/(p(Z)) ^ F2OS). 

The set of elements {l,/3, . . . ,y6""') is a basis of ¥2" as a vector space over F2 and 
we can represent a generic element of F2» as a polynomial in jS of degree lower than n: 

n-l 

F2" 9 a = ^ ai0 = Un-ip''^ + • • • + aiyS + ao , a, e F2 . 

1=0 

Moreover, the isomorphism F2« - ¥2[X\l{p{X)) allows us to implement the arithmetic 
of F2» relying on the arithmetic of F2[X] and reduction modulo p{X). 

Since each element a, e F2 can be encoded as a bit, we can represent each element 
of F2" as a Church word of bits of type L2. 

In what follows, we denote by n the Church numeral representing n = deg p{X), and 
by p the Church word: p = {pn-.-po J-_;^^_^} , where p, are such that p{X) = 2 piX'. 

n-l 

Note that p has length 2n - 1. The ± in the least significative part are included for 
technical reasons, to simpUfy the discussion later. 

Addition. Let a,b e ¥2". The addition a + bis computed component- wise, i.e., setting 

a = ciiP' and b = Yj b fi' , then a + b - XK^i + bi)/3'. The sum (a, + b,) is done in F2 and 
corresponds to the bitwise exclusive or. This led us to the following definition: 
The combinator Add : F2" -0F2'" -oF2» is: 

Add = MapThread[Xor] (8) 

Modular Reduction. Reduction modulo piX) is a fundamental building block to keep 
the size of the operands constrained. We implemented a naif left-to-right method, as- 
suming that: (1) both p(X) and n - deg p(X) are fixed (thus axioms); (2) the length of 
the input is 2n, i.e. we need exactly n repetitions of a basic iteration. 
The combinator wMod[n, />] : L2 -o §F2» is: 

wMod[n,p] = /W.(§[wModEnd]) 

((n) /l/.((MapState[wModFun]) /) {±, (Sl» (wModBase|>]) (wCast") d 

where: 

wModEnd = /l/.(wDrop±) (wRev) (wProj) / 
wModFun = A{e, s).(A{d, p).(A{sQ, si). 

(((((((*o) Adps.(A(p',p").{mor) d) p', s), <1, p"))) m) P) ) 

Adps.iid, s),(0,p») 

Adps.{{±, s), (d, p})) d) p) si 

)s)e 

wModBase|>] = /W.((MapThread[/la./lZ>.(a, b)]) (wRev) d) (wRev) p 



The basic iteration is implemented via MapState[-], that operates on a list of bit pairs 
{. . . (d,-, p,) . . .}, where d,- are the bits of the input and p, the bits of p. The core of the 
algorithm is the combinator wModFun : (Bj ® B2) -o (Bj ® Bj), that behaves as follows: 

((wModFun) <d^) (so^Pm) li (<d,',p,.n),<So'^,p,)) , 

elem. e status s e' s' 

where sq keeps the m.s.b. of {. . . d, . . .) and it is used to decide wether to reduce or not 
at this iteration. Thus, d,' = d,- + p,- if Sq = 1; d,' - d, if Sq = 8; and d/ = ± when 
So = -L (that represents the initial state, when sq still needs to be set). 

Note that the second component of the status is used to shift p (right shift as the 
words have been reverted). 



Square. Square in binary fields is a linear map (it is the absolute Frobenius automor- 
phism). If fl £ F2" , a - J] UiP' , then -Y^ a fi^' . This operation is obtained by inserting 
zeros between the bits that represent a and leads to a polynomial of degree 2n - 2, that 
needs to be reduced modulo p{X). 

Therefore, we introduce two combinators: wSqr : L2 ^ L2 that performs the bit 
expansion, and Sqr : F2" -o §F2" that is the actual square in F2" . We have: 

Sqr = /la.(wMod[n, pj) (wSqr) a (9) 

and wSqr = /l//x.((0 wSqrStep[/]) x, where wSqrStep[/] = /let((/) 0) ((/) e) ^ has 
type B2 -o a -o a if / is a non Unear variable with type B2 -o a -o a. 



Multiplication. Let a,b €¥2". The multiplication ab is computed as polynomial mul- 
tiplication, i.e., with the usual definition, ab - Yii+k=ii^j + bk)P'. 

We currently implemented the naive schoolbook method. A possible extension to 
the comb method is left as future straightforward work. On the contrary, it is not clear 
how to implement the Karatsuba algorithm, which reduces the multiplication of n-bit 
words to operations on n/2-bit words. The difficulty is to represent the splitting of a 
word in its half upper and lower parts. 

Similarly as for the square, we have to distinguish between the polynomial multi- 
phcation wMult : L2 -o L2 -o §L2 and the field operation Mult : F2" -° F2" -o §^F2", 
obtained by composing with the modular reduction. We have: 

Mult s ^fl/7.(§[wMod[H,p]])((wMult)a)/7 
wMult = /la^.(§[wProj 2]) {{b) /lM/.((wMultStep) <M, ±)) /) (wMultBase) (wCast*^) a 

The internals of wMult are in Figure 6. It implements two nested iterations. The 
parameter b controls the external, and a the internal one. 

The external iteration (controlled by b) works on words of bit pairs. The combinator 
wMultStep : B| ^L(B^) ^L(B^) behaves as follows: 



((wMultStep) (M, ±» Afx. . . . ((/) <m,-, r,» . . .x \l Afx. . . . (if) <m,_i, r;» ...x 



wMultStep 


= /li//x.(wBMult[/]) ((0 MSStep[/, wFMult]) (MSBaseM) (tCast") s 


wMultBase 


= im.((MapThreadUa.^fc.<a, h}])m) {e\ 


MSStep[/,wFMult] 


= Ae.Aiw, s).me', s'}.{((f) e') w, s')) ((wFMult) e) s 


MSBaseM 


= As.(x, s) 


wFMult 


= Aim, r).A{M, m).{A{m', m").(A(M', M"). 




{{in, ((Xor) ((And) m') M'} r), {M" , m"» 




) (bV2) m) (bVz) M 


wBMult[/] 


= A{w, s}.(A{M, m}.((f) {m, S» w) s 



Fig. 6. Multiplication: definition of the combinators 



where M is the current bit of the Multiplier b, and every m, is a bit of the multiplicand 
a, and every r, is a bit in the current result. The iteration is enabled by the combinator 
wMultBase : Li-oLCBj), that, on input a, creates /l/x.((/)(m„_i,±)) ...((/) (mo, ±)) x, 
setting the initial bits of the result to ±. The projection wProj2 returns the result when 
the iteration stops. 

The internal iteration is used to update the above list of bit pairs. The core of this 
iteration is the combinator wFMult : -o -o (Bj ® B|), that behaves as follows: 

((WFMult) <mi, r,)) (M,m,-i) Ij. ( (m,-i,M • m,- + r^) , (M,m,» . 

elem. e status s e' s' 

For completeness, we list the type of the other combinators: MSStep[/, wFMult] : Bj -o 
(a®B2)^(a(g)B2) , MSBase[x] : B^ ^(a (g) B^) , wBMult[/J : (a(8)B2)^a . 

Inversion. It is under development. We are concentrating on the binary Euclidean al- 
gorithm, which is the "left-to-right" counterpart of the extended Euclidean algorithm 
(for a detailed analysis, we refer to Pong et al. [13]). 

4 Developing (with) the Library 

Beside the implementation of the library, we experimented the use of higher-order com- 
binators to improve the readability of the code, as well as the programming experience. 
Inspired by [5], we have rewritten some combinators relying on standard programming 
pattern such as Map[-] and Fold[-, •], "simulating" the behavior of a programmer that 
wants to add new functionality to the library. The idea is to let the programmer write 
a combinator in a more comfortable style, and then to compile the combinator to a 
value that admits a type in DLAL. In the following, we give some relevant examples of 
increasing difficulty. 

We know that w2s is defined as w2s = Al.iif) Aestc.{c) {e, s))[e\. A programmer 
could anyway define it by using the standard programming pattern Fold[-, •] as follows: 



w2sFromFold = Fold[/le i?c.(c) <e, s), [e]] 



The combinator w2sFromFold is a legal one because w2sFromFold compiles exactly 
to w2s. The compilation consists of in-line substituting the parameters of Fold[-, •] 
and of applying the rewriting steps in Figure 1, whose key intermediate /l-terms are 

Al.((l) Aez.Utc.ic) {e, z» e) |e] and M.((l) Aeztc.(c) {e, z}) [s]. 

As a second example, we consider the combinator wPro j = Al fx.({l) A{a, b).{f) a) x, 
we define the following combinator and we show that it is equivalent to the above one: 

wProjFromMap = Map[/l(a, /7).fl] 

We recall that wPro j : L(B2) -o L2. While compiling the expression, we need the as- 
sumption that each element e of the input word is (a', b') : The key step is the reduc- 
tion from Alfx.((l)Ae.(f)(A{a,b}.a)e)x to Alfx.{{l) A{a' ,b').{J){A{a,b).a) {a' ,b')) x , 
by replacing {a', b') for e in accordance with the assumption. 

Finally, we show that the combinator Map[F] = Alfx.{{l) Ae.{f) (F) e) x can be writ- 
ten using Fold[-, •] (see also [5, Section 2]) as: 

MapFromFold[F] = 7o\d[Aepfx.{{f) (F) e) {(p) /) x, {e}] 

Here, the compilation process shows that (Map[F]) and (MapFromFold[F]) I' are equiv- 
alent to the same value. We proceed by induction on the length of the Church word /'. 
First, we note that: 

MapFromFoldlFI ^ AUil) Aep fx. ({/)(¥) e)(ip)f)x) [e] 

The base case is easy to check: (Map[F]) {s] U {e) and (MapFromFold[F]) [s] U, [s]. 

We now prove the inductive case. Let / = Afx.{{f) b„-i) . . . ((/) bo) x be a Church 
word of length n. Assume that (Map[F]) I JJ, V and (MapFromFold[F]) Z V. We want 
to show that Map[F] and MapFromFold[F] reduce to the same term for a Church word 
/' = Afx.iif) b) ((/) f)xof length n+l. We report the key intermediate l-terms: 

(Map[F]) /' W. Afx.m Ae.if) (F) e) x 

]^Afx.{{f){7)h){{DAe.{f){Y)e)x (10) 

ind. hyp. U Afx.iif) (F) b) (( V) /) X (11) 

(MapFromFold[F]) I' U ((/') Aepfx.((f) (F) e) ((p) f) x) {s} 

U {{Aepfx.{{f) (F) e) ((p) f) x) b) ((/) Aepfx.((f) (F) e) ((p) f) x) {s} 
ind. hyp. U ((Aepfx.df) (F) e) {(p) /) x) b) V 
\i Afx.iif) {F)b){{V)f)x 

This example is particularly relevant because MapFromFold[F] : L(A) -o §L(B), and 
Map[F] : L(A) -o L(B) compile to a common term despite their types differ. This is 
possible by applying two j6-expansions from (10) to (11) which do not duplicate any 
structure. 

5 Conclusion and Future Work 

We have presented a core library for binary field arithmetic developed DLAL. The main 
motivation behind this work is to achieve a programming framework with built-in poly- 
nomial complexity and, from this perspective, this library is just a starting point, as 



it lacks inversion and a complete realistic applicative example, such as elliptic curves 
cryptography. In the same line, the implementation of symmetric-key cryptographic al- 
gorithms (block/stream ciphers, hash functions, . . . ) looks attractive as well, thanks to 
the higher-order bitwise operations at the core of the current API. 

Next, we shall investigate a full compilation process whose target will be machine 
code. Namely, we plan to go further beyond the first compilation phase of Section 4, 
where, in fact, we describe an in-line parameters unfolding of standard programming 
patterns Uke Map[-] and Fold[-, ■]. The compilation to machine code will target par- 
allelization, generally implied by functional progranuning thanks to its reduced data 
dependency. 

Interestingly, while programming the binary field arithmetic, we found that the main 

programming patterns we used can be assimilated to the MapReduce paradigm [14]. 
This means that not only DLAL can be used to certify polynomial-time complexity, but 
it is also suitable to be adapted to actual cloud platforms based on the MapReduce. 

Finally, we do not exclude that more refined logics than DLAL can be used to realize 
a similar framework with even better built-in properties. Our choice of DLAL originated 
as a trade-ofF between flexibiUty in programming and constrains imposed by the typ- 
ing system, but it is at the same time an experiment. Dififerent logics can for instance 
measure the space complexity, or provide a more fine-grained time complexity. 
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A Definition of Combinators 

bCast'" is Ab.{{{b) 1) 8) ±. 

t I I 

bV, is Ab.iiib) (TT^)) (sT^)) (±7^), for every t > 2. 
tCast™ is, for every m > 0: 

tCast" = A{a, bUiiia) <1, 1)) <1, 0» (1, ±)) 

ax((W<0,l))(8,0»<0,±» 

ax((W<±,i))(±,0»<±,±»fo 
tCast'""'! =/lp.(§[tCast'"])(tCast'')p . 

wSuc is Abp.AfxXif) (bCast") b) {{p) f) x. 
wCast™ is, for every m > 0: 

wCast" = Al.mi) (wSuc) 0) (wSuc) 1) (wSuc) ±) {e} 

wCast"*-"! =/lZ.(§[wCast'"])(wCast'')Z . 

wVJ", for every t>2, and m > is: 

wV? = AI.{{{1) (wVStep) 0) (wVStep) 1) wVBase 

wVf-'i =/l/.(§[wVn)(wV?)/ 

wVStep = A\3.A{x\ . . . X;).<((wSuc) b) xi . . . ((wSuc) b) X;) 

t 

wVBase = <{e} . . . {e}) . 

Xor is: Abc.mb) Ax.{{{x) 0) 1) 1) Ax.(((x) 1) 0) 0) Ax.x) c. 

And is A})c.{{{{b) Ax.x) Ax.{{{x) 0) 0) ±) ±) c. 

sSpl is /ls.(('S)^f-(-L, [e]»/lx:.x. 

wRev is Alfx.(((l) wRevStep[/]) Ax.x) x with: 

wRevStep[/] = Aerx.ir) ((/) e) x : Bi -o (a -o a) -o or -o a, when / : B2 -o a -o a. 
wDrop± is Alfx.iiD Ae.me) Af.{f) 1) Af.{f) 0) i/z.z) /) x. 
w2s is AI.{{1) Aestc.{c) (e, s)) [e]. 
wPro j is Alfx.((l) A{a, b).{f) a) x. 
wPro j 2 is Alfx.{{l) A{a, b}.(f) b) x. 
Map[F] is Alfx.iil) Ae.{ f) (F) e) x, with F : A^B closed. 

Fold[F, S] is Al.iil) Aez.HF) e) z) (Cast") S, with F:A-oB-oB, aiidS:B closed. 
MapState[F] is Alsfx.(A{w, s'}.w) ((l)K.SStep[F, f]){K.SBase[x]){Cast'^) s, with 

F : (A®5)^(B(8>5) closed, and: 

MSStep[F,/] = Ae.A{w,s}.iA{e',s').{(if)e')w,s'))iF){e,s) : iA<2>S)^ia^S)^ia<2>S) 
MSBase[x] = As.{x, s) : S ^(o-g.^) . 

MapThread[FJ is Mmfx.(A{w, s).w) {(I) MTStep[F, /]) (MTBase[x]) (w2s) (wRev) m, with 
F : A -oB-oC closed, (w2s) (wRev)OT : §S, whenever m : L2, and: 

MTStep[F, /] = Aa.A{w, s).{A{b, *').<((/) ((F) a) b) w, s')) (sSpl) 5:82^ (a®S) -o (a®S) 
MTBase[x] = Ax.{x,m) : a-oa®S . 



